home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 24 / AACD 24.iso / AACD / Graphics / TVPaint / Things / deepform.txt
Text File  |  1995-11-07  |  12KB  |  428 lines
  1. ************************************************************************
  2.  
  3. FRANÇAIS
  4. --------
  5. DEEP est un format d'image IFF standard (Interchange Format File)
  6. au même titre que l'ILBM. Nous vous en rappelons ici la description
  7. officielle agrémentée de la description du format d'icône utilisé par
  8. TVPaint 3.0 et Broadcast Painter.
  9.  
  10.  
  11.  
  12. ENGLISH
  13. -------
  14. Here is an offcial description of the DEEP file format, a standard
  15. IFF (Interchange Format File) just as the ILBM. See also the description
  16. of the saved-in icon used by TVpaint 3.0 and Broadcast Painter.
  17.  
  18.  
  19. ************************************************************************
  20.  
  21. CONCEPTS
  22. --------
  23. Un fichier IFF commence par les 4 lettres FORM, un MOT LONG (32 bits)
  24. qui contient la taille de ce qui suit, 4 lettres d'identification du
  25. type de format (ici DEEP), puis une série de chunks. Cette entête permet
  26. de reconnaître le format sans tenir compte des extension du nom du
  27. fichier. Cette extension (.dip) doit tout de même être sauvegardée dans
  28. le monde PC/Windows pour pallier à la gestion anarchique des autres
  29. formats...
  30.  
  31. Le format IFF se compose de différents "chunk" qui contiennent chacun
  32. des données particulières (palette, icône, informations, son, pixels...). 
  33.  
  34. Un chunk commence TOUJOURS par 4 caractères (lettres) d'identifications,
  35. suivis d'un MOT LONG (32 bits) qui contient la taille des données sui-
  36. vantes, suivi des données elles-mêmes.
  37.  
  38. Le chunk suivant se trouve juste après, ALIGNÉ SUR UN MOT SHORT (16 bits)
  39.  
  40. TOUTES les valeurs sont écrites en BIG INDIAN (valeur la plus
  41. significative, octet de poids fort en premier).
  42.  
  43.  
  44.  
  45. CONCEPTS
  46. --------
  47. An IFF file begins with the 4 letters FORM, a LONG WORD (32 bits)
  48. which contains the size of the following then 4 identification letters
  49. of the format type (here it is DEEP) and then a series of chunks. This
  50. heading enable to identify without taking in account the extension in
  51. the file name. Unfortunately this extension (.dip) must be saved in the
  52. PC/Windows world because of the lack of intelligent format...
  53.  
  54. The IFF format is composed with different chunks each contain specific
  55. datas (color palette, icon, informations, sound, pixels...)
  56.  
  57. A chunk ALWAYS begins with 4 identification characters (letters),
  58. then a LONG WORD (32 bits) which contain the size of the following datas,
  59. then the datas themselves.
  60.  
  61. The next chunk is placed just after, ALIGNED ON A SHORT WORD (16 bits).
  62.  
  63. EVERY values are written in BIG INDIAN mode (the most significant value
  64. first).
  65.  
  66.  
  67. ************************************************************************
  68.  
  69. IFF FORM / CHUNK DESCRIPTION
  70.  
  71. Form / Chunk ID :    FORM  DEEP    (Deep pixels)
  72.             Chunk DGBL    (Deep GloBaL information)
  73.             Chunk DPEL    (Deep Pixel ELement)
  74.             Chunk DLOC    (Deep display LOCation)
  75.             Chunk DBOD    (Deep data BODy)
  76.             Chunk DCHG    (Deep CHanGe buffer)
  77.  
  78.  
  79. ** FORM  ***************************************************************
  80.  
  81. FORM ID :     DEEP        (DEEP pixels)
  82.  
  83. FORM purpose :
  84. To allow faster loading and saving of images when pixels are stored in
  85. consecutive memory locations and provide support for common extensions
  86. implemented on advanced graphics cards.
  87.  
  88. FORM description :
  89. This FORM is designed to provide support for a variety of deep pixels,
  90. included 24 bits images. A deep pixel is one in which the pixel value
  91. is used to directly produce the output colour without the use of a color
  92. look-up table and also where the pixel stored in consecutive memory
  93. locations. The format allows additional bits to be stored along with the
  94. color bits to provide support for additional features such as masks,
  95. Z-buffers, linear keys, etc.
  96.  
  97. The format is designed to allow different colour formats to be stored
  98. such as RGB, RGBA, YCM and YCMB with varying depths supported. Bit
  99. ordering will be most significant bit first.
  100.  
  101.  
  102. **  CHUNKS  ************************************************************
  103.  
  104. Chunk ID :    DGBL        (Deep GloBaL information)
  105.  
  106. Chunk purpose :
  107. Provide global information of relevance to all the data contained in
  108. the file. DGBL will always be the first chunk in the file.
  109.  
  110. Chunk description :
  111. Used to provide information that is constant for all contents of the
  112. file. One chunk is mandatory at the start of the file. When the file
  113. is used to store a group of images it may, in  exceptional circum-
  114. stances, be necessary to add additional DGBLchunks. The contents of
  115. a DGBL chunk remain valid until anotherDGBL chunk is encountered.
  116.  
  117. ****************************************
  118.  
  119.  
  120. Chunk ID :    DPEL        (Deep Pixel ELement)
  121.  
  122. Chunk purpose :
  123. Defines the contents of each pixel. Enables the data content to be
  124. identified and handled. Data that is unknown or not required can be
  125. discared.
  126.  
  127. Chunk description :
  128. This chunk is best described by an example :
  129.  
  130.     Original data = RGBA 8,8,8,4
  131.  
  132.     DPEL =    4        (number of elements)
  133.             RED        (first element)
  134.             8        (bits in element)
  135.             GREEN    (second element)
  136.             8        (bits in second element)
  137.             BLUE        (third element)
  138.             8        (bits in third element)
  139.             ALPHA    (fourth element)
  140.             4        (bits in fourth element)
  141.  
  142.     Stored data (binary) = rrrrrrrr gggggggg bbbbbbbb aaaa0000
  143.  
  144. Note : The pixel has been padded to the next byte boundary.
  145.  
  146.  
  147. The element must be defined in the order in which they are stored,
  148. with the most significant bit first.
  149.  
  150. ****************************************
  151.  
  152.  
  153. Chunk ID :    DLOC        (Deep display LOCation)
  154.  
  155. Chunk purpose :
  156. Provides information specific to the following DBOD section. Enables
  157. image sections to be located within the screen areas individually and
  158. allows images with a size different to DisplayWidth and DisplayHeight
  159. to be stored.
  160.  
  161. Chunk description :
  162. Specifies the width, height and where to place the following Deep data
  163. BODy. If no DLOC is encountered before a DBOD, the DisplayWidth and
  164. DisplayHeight parameters will be used as the DBOD image data dimensions.
  165. The contents of a DLOC chunk remain valid until another DLOC chunk is
  166. encountered.
  167.  
  168. ****************************************
  169.  
  170.  
  171. Chunk ID :    DBOD        (Deep BODy)
  172.  
  173. Chunk purpose :
  174. Contains the image data.
  175.  
  176. Chunk description :
  177. Contains image data compressed by the method defined in DGBL. The image
  178. size and the location where it is to be displayed is provided by a DLOC
  179.  chunk. If no DLOC chunk has been read the data will be displayed in the
  180. upper left corner and will be DisplayWidth wide and DisplayHeight high.
  181.  
  182. ****************************************
  183.  
  184.  
  185. Chunk ID :    DCHG        (Deep CHanGe buffer)
  186.  
  187. Chunk purpose :
  188. Informs the IFF reader that a complete frame has been read. Only required
  189. when multiple images are stored for cell animation.
  190.  
  191. Chunk description :
  192. When a chunk is encounter the IFF reader knows that a complete frame has
  193. been read. The chunk gives the time, from the last frame change, before
  194. the frame should be changed again. If the time has already elapsed the
  195. frame should be changed immediatly. A FrameRate of 0 will cause the
  196. frame changes to occur as fast as possible. A FrameRate of -1 is used to
  197. indicate the end of the data for one frame and the start of the next in
  198. cases where multiple frames are stored but are not intended for animation.
  199. A DCHG chunk is not required when only a single frame is stored.
  200.  
  201. ****************************************
  202.  
  203.  
  204. Chunk ID :    XS24        (eXtra Small 24 bit image)
  205.  
  206. Chunk purpose :
  207. Contain a small image which is supposed to be an 24 bit icon of the
  208. file.
  209.  
  210. Chunk description :
  211. This icon is currently generated (and displayed) by TVPaint3 and Broadcast
  212. Painter. The icon should have a maximum size of 64 pixels by 64 pixels.
  213. When the creation of the image, it should be PROPORTIONALLY reduced to
  214. enter in these dimensions: the biggest dimension (X or Y) of the image
  215. should be equal to 64. 
  216.  
  217. The small image is NOT compressed. It is a raw format: RGBRGBRGB... with
  218. ONLY RGB values.
  219.  
  220.  
  221. **  FORM DEEP  ***********************************************************
  222.  
  223.  
  224. // chunk DGBL
  225. Struct DGBL = {
  226.         UWORD    DisplayWidth, DisplayHeight;
  227. //            size of source display
  228.  
  229.         UWORD    Compression;
  230. //            type of compression
  231.  
  232.         UBYTE    xAspect, yAspect;
  233. //            pixel aspect, a ratio w/h
  234.         };
  235.  
  236.  
  237.  
  238. // chunk DPEL
  239. Struct DPEL = {
  240.         ULONG    nElements;
  241. //            Number of pixel components
  242.         Struct TypeDepth = {
  243.  
  244. // The TypeDepth structure is repeated times to  identify the content
  245. // of every pixel. Pixels will always be padded to byte boundaries.
  246. // The DBOD chunk will be padded to an even longword boundary.
  247.                     UWORD    cType;
  248. //                        type of data
  249.  
  250.                     UWORD    cBitDepth;
  251. //                        Bit depth of this element
  252.                     } typedepth [ Nelements ];
  253.         };
  254.  
  255.  
  256.  
  257. // chunk DLOC
  258. struct DLOC = {
  259.  
  260.         UWORD    w,h;
  261. //            Body width and height in pixels
  262.  
  263.         WORD    x,y;
  264. //            Pixel position for this image
  265.         };
  266.  
  267.  
  268.  
  269. // chunk DBOD
  270. pixel (0), pixel (2), pixel (3),...  pixel (w-1), 
  271. pixel (((h-1)*w)),...   pixel(h*w-1)
  272.  
  273.  
  274.  
  275. // chunk DCHG
  276. struct DCHG = {
  277.         LONG        FrameRate;
  278. //            Animation control when multiple images are stored
  279. //            FrameRate - milliseconds between frames changes
  280.         };
  281.  
  282.  
  283.  
  284. // chunk TVDC
  285. struct TVDC = {
  286.         WORD    Table[16];
  287.         };
  288.  
  289.  
  290. // chunk XS24
  291. struct XS24 = {
  292.         WORD    Width,Height;
  293.         WORD    type; /* type MUST BE equal to 0 (zero) */
  294.         };
  295.  
  296.  
  297. ****************************************
  298.  
  299. Compressions currently defined :
  300.     NOCOMPRESSION    =    0
  301.     RUNLENGHT        =    1
  302.     Reserved            =    2
  303.     Reserved            =    3
  304.     Reserved            =    4
  305.     DELTA or TVDC    =    5
  306.     Reserved            =    6
  307.     Reserved            =    7
  308.  
  309.  
  310. Ctype currently defined :
  311.     RED        =    1
  312.     GREEN        =    2
  313.     BLUE        =    3
  314.     ALPHA        =    4
  315.     YELLOW    =    5
  316.     CYAN        =    6
  317.     MAGENTA    =    7
  318.     BLACK        =    8
  319.     MASK        =    9
  320.     ZBUFFER    =    10
  321.     OPACITY    =    11
  322.     LINEARKEY=    12
  323.     Reserved    =    13
  324.     Reserved    =    14
  325.     Reserved    =    15
  326.     Reserved    =    16
  327.     DENSITY    =    17
  328.  
  329.  
  330. *****  DELTA decompression routine  ************************************
  331.  
  332. Routine de décompactage du format TVDC. Notez que la compression est
  333. faite ligne à ligne pour chaque élément du chunk DPEL. Pour RGBA on
  334. trouve une ligne Rouge, une ligne Verte, etc...
  335.  
  336. Here is a decompression routine for the DELAT format. Note that the
  337. compression is made line by line for each element of the DPEL chunk.
  338. For RGBA, there is a red line, a green line, etc...
  339.  
  340.  
  341.  
  342. CDepackTVDC(source,dest,table,size)
  343. UBYTE    *source;
  344. UBYTE    *dest;
  345. WORD    *table;
  346. int    size;
  347. {
  348. int    i;
  349. int    d;
  350. int    pos=0;
  351. UBYTE    v=0;
  352.  
  353.     for(i=0;i<size;i++)
  354.     {
  355.         d=source[pos>>1];
  356.         if(pos++ & 1)    d&=0xf;
  357.         else        d >>=4;    
  358.  
  359.         v+=table[d];
  360.         dest[i]=v;
  361.  
  362.         if(!table[d])
  363.         {
  364.             d=source[pos>>1];
  365.             if(pos++ & 1)    d&=0xf;
  366.             else        d >>=4;    
  367.  
  368.             while(d--)    dest[++i]=v;
  369.         }
  370.     }
  371.     return((pos+1)/2);
  372. }
  373.  
  374.  
  375.  
  376. *****  DEEP decompression routine  ************************************
  377.  
  378. Routine de décompactage du format DEEP. Notez que la compression est
  379. faite ligne à ligne pour chaque pixel.
  380.  
  381. Here is a decompression routine for the DEEP format. Note that the
  382. compression is made LINE by LINE for each pixel.
  383.  
  384.  
  385.  
  386. UBYTE *DecodeDeep(UBYTE *source,Pixel *point,int size)
  387. {
  388. int    a,b;
  389.  
  390.     while(size>0)
  391.     {
  392.  
  393.         a = *((BYTE*)source++);
  394.  
  395.         if(a == -128)
  396.         {
  397.             /* nothing */
  398.         }
  399.         else
  400.         if(a>=0)
  401.         {
  402.             a = a + 1;
  403.             memcpy(point,source,a*sizeof(Pixel));
  404.             source += sizeof(Pixel)*a;
  405.             point += a;
  406.             size  -= a;
  407.         }
  408.         else
  409.         {
  410.             a = -a + 1;
  411.             b=a;
  412.             while(b--)
  413.             {
  414.                 memcpy(point,source,sizeof(Pixel))
  415.                 source += sizeof(Pixel);
  416.             }            
  417.             point += a;
  418.             size  -= a;
  419.         }
  420.     }
  421.  
  422.     return(source);
  423. }
  424.  
  425.  
  426.  
  427.  
  428.